1. Field of the Invention
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for multiple process coordinating. Still more particularly, the present invention provides a method and apparatus for process scheduling or resource allocation during task management or control using mutual exclusion locks (mutexes).
2. Description of Related Art
Modern operating systems support multiprogramming, whereby multiple programs appear to execute concurrently on a single computational device with a single central processing unit (CPU) or possibly multiple CPUs in a symmetric multiprocessor (SMP) machine. The appearance of concurrent execution is achieved through the use of serialized execution, also known as “time slicing”: the operating system of a device allows one of the multiple programs to execute exclusively for some limited period of time, i.e., a time slice, which is then followed by a period of time for the exclusive execution of a different one of the multiple programs. Because the switching between programs occurs so quickly, it appears that the programs are executing concurrently even though they are actually executing serially. When the time slice for one program is concluded, that program is put into a suspended or “sleep” state, and another program “awakes”and begins to execute.
One way of improving the performance of a single program or a single process is to divide the program or the process into paths of execution, often termed “threads”, that appear to execute concurrently. Such a program or process is typically described as “multitasking” or “multithreaded”; the operating system provides each thread with a time slice during which it has exclusive use of the CPU. Operating systems typically provide built-in mechanisms for switching between concurrent programs and/or threads in a very quick and efficient manner; some types of CPUs provide direct hardware support to an operating system for multithreading. Because the concepts of the present invention apply equally to concurrent threads and concurrent programs, which may comprise a single thread or multiple threads, the term “thread” as used herein may refer to a non-multithreaded program or to one thread within a multithreaded program.
As threads execute, they invariably need to access resources within a data processing system, such as memory, data structures, files, or other resources. Resources that are intended to be shared by multiple threads must be shared in such a way to protect the integrity of the data that is contained within the resource or that passes through the resource; one way of effecting this is by means of serializing execution of threads that are competing for a shared resource. When a first thread is already using a resource, a second thread that requires the resource must wait until the resource is no longer being used, which would typically occur as a consequence of the first thread having successfully completed its use of the resource.
An operating system typically provides multiple mechanisms for coordinating the use of shared resources by multiple threads. Although an application developer could create her own specific mechanisms for ensuring serialized access to shared resources, an application developer usually employs the mechanisms that are provided by an operating system or within a standardized software library to embed control logic for sharing resources into multiple threads. The use of operating-system-specific mechanisms is advantageous because it allows an operating system to integrate information about the competition for resources into its time slicing functionality. Hence, an operating system allocates time slices to threads in accordance with their needs and their competition for resources rather than through the use of strictly periodic time slices.
A common mechanism for serializing access to a shared resource is a mutex, or mutual exclusion lock, which is a simple lock having two states: locked and unlocked. The lock is typically implemented as a data object or a data structure that is created, destroyed, or modified via a software subroutine or module in a standardized library of routines. A mutex can be logically associated with a shared resource such that a thread that successfully locks the mutex is said to be the current owner of the mutex; only the thread that possesses a particular mutex should proceed to access the shared resource that is associated with that particular mutex, and only the thread that possesses a particular mutex should unlock that particular mutex. Thus, a critical section of code within a thread that accesses a shared resource is bounded by a call to lock a mutex and a call to unlock the same mutex. If a thread attempts to lock a mutex and fails, then it must wait until it is able to lock the mutex before proceeding to execute its critical section of code in which it accesses the shared resource. A mutex can be used to synchronize threads within a single process or across multiple processes if the mutex is allocated within memory that is shared by the coordinating processes.
The manner in which a thread waits for a mutex after failing to acquire the mutex depends on the manner in which the mutex mechanism is implemented. Three types of locks are widely used: a blocking lock, a spin lock, and some type of combination of a blocking lock and a spin lock. If a mutex has already been acquired and another thread requests to lock the mutex, then a mutex that is implemented as a blocking lock causes the waiting thread to cease being executable or to be suspended, i.e., to go to “sleep”. In contrast, spin locks do not put waiting threads to sleep. Instead, a waiting thread executes a loop, thereby repeatedly requesting the lock until it is freed by the thread that currently owns the mutex; the loop may contain an empty, iterative loop, i.e., “busy loop” or “busy wait”, that increments or decrements a variable such that the thread does not immediately re-request the mutex but waits for a period of time that depends on the length of the iterative loop.
In contrast to a blocking lock or a spin lock, a mutex is often implemented as a spin lock with a timeout, which is a lock that combines the characteristics of a blocking lock with the characteristics of a spin lock. A spin lock with a timeout spins for a limited period of time while allowing the thread to attempt to re-acquire the lock; if the limited period of time expires without acquiring the lock, then the thread is blocked. The time period for the timeout is usually controlled by executing a fixed number of iterations in a busy-wait loop. In addition to a lock routine and an unlock routine, software libraries often contain a “trylock” subroutine in which control is returned to the requesting subroutine if the mutex is not acquired, i.e., the requesting routine is not forced to wait for the mutex to become available.
The actions of blocking and spinning have their advantages and disadvantages. Blocking quickly suspends the execution of a waiting thread. However, the action of blocking may suspend a thread that would soon acquire the lock, and the suspension of a thread entails relatively significant overhead, e.g., the thread's execution context must be saved. Spinning consumes resources, such as CPU time and memory cache lines, but if the length of the spinning period is selected judiciously, then a waiting thread may often acquire a mutex relatively quickly, thereby allowing a spinning operation to consume less computational resources than a blocking operation. However, the choice between spinning and blocking depends on many factors, particularly the computational environment of the device on which a waiting thread is executing.
In order to improve performance, the spin lock timeout is often adjustable. Some operating system kernels allow the length of a spin timeout to be adjustable on a system-wide basis. In other cases, the spin lock timeout is adjustable on a per-application basis. The value of the spin lock timeout may be read from a configuration file or a property file that provides runtime or environment variable values. However, finding an appropriate value for the spin lock timeout can be a time-consuming task that is performed by a system administrator.
Therefore, it would be advantageous to have a mutex that is implemented as a spin lock with a timeout that does not require an extensive hand-tuning process.